Data profiling

ABSTRACT

Processing data includes profiling data from a data source, including reading the data from the data source, computing summary data characterizing the data while reading the data, and storing profile information that is based on the summary data. The data is then processed from the data source. This processing includes accessing the stored profile information and processing the data according to the accessed profile information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/519,030, filed Oct. 20, 2014, which is a continuation of U.S.application Ser. No. 10/941,402, filed Sep. 15, 2004, which claims thebenefit of U.S. Provisional Application No. 60/502,908, filed Sep. 15,2003, No. 60/513,038, filed Oct. 20, 2003, and No. 60/532,956, filedDec. 22, 2003. The above referenced applications are incorporated hereinby reference.

BACKGROUND

This invention relates to data profiling.

Stored data sets often include data for which various characteristicsare not known beforehand. For example, ranges of values or typicalvalues for a data set, relationships between different fields within thedata set, or functional dependencies among values in different fields,may be unknown. Data profiling can involve examining a source of a dataset in order to determine such characteristics. One use of dataprofiling systems is to collect information about a data set which isthen used to design a staging area for loading the data set beforefurther processing. Transformations necessary to map the data set to adesired target format and location can then be performed in the stagingarea based on the information collected in the data profiling. Suchtransformations may be necessary, for example, to make third-party datacompatible with an existing data store, or to transfer data from alegacy computer system into a new computer system.

SUMMARY

In one aspect, in general, the invention features a method andcorresponding software and a system for processing data. Data from adata source is profiled. This profiling includes reading the data fromthe data source, computing summary data characterizing the data whilereading the data, and storing profile information that is based on thesummary data. The data is then processed from the data source. Thisprocessing includes accessing the stored profile information andprocessing the data according to the accessed profile information.

In another aspect, in general, the invention features a method forprocessing data. Data from a data source is profiled. This profilingincludes reading the data from the data source, computing summary datacharacterizing the data while reading the data, and storing profileinformation that is based on the summary data. Profiling the dataincludes profiling the data in parallel, including partitioning the datainto parts and processing the parts using separate ones of a first setof parallel components.

Aspects of the invention can include one or more of the followingfeatures:

Processing the data from the data source includes reading the data fromthe data source.

Profiling the data is performed without maintaining a copy of the dataoutside the data source. For example, the data can include records witha variable record structure such as conditional fields and/or variablenumbers of fields. Computing summary data while reading the dataincludes interpreting the variable record structure records whilecomputing summary data characterizing the data.

The data source includes a data storage system, such as a databasesystem, or a serial or parallel file system.

Computing the summary data includes counting a number of occurrences foreach of a set of distinct values for a field. The profile informationcan include statistics for the field based on the counted number ofoccurrences for said field.

A metadata store that contains metadata related to the data source ismaintained. Storing the profile information can include updating themetadata related to the data source. Profiling the data and processingthe data can each make use of metadata for the data source

Profiling data from the data source further includes determining aformat specification based on the profile information. It can alsoinclude determining a validation specification based on the profileinformation. Invalid records can be identified during the processing ofthe data based on the format specification and/or the validationspecification.

Data transformation instructions are specified based on the profileinformation. Processing the data can then include applying thetransformation instructions to the data.

Processing the data includes importing the data into a data storagesubsystem. The data can be validated prior to importing the data into adata storage subsystem. Such validating of the data can includecomparing characteristics of the data to reference characteristics forthe data, such as by comparing statistical properties of the data.

The profiling of the data can be performed in parallel. This can includepartitioning the data into parts and processing the parts using separateones of a first set of parallel components. Computing the summary datafor different fields of the data can include using separate ones of asecond set of parallel components. Outputs of the first set of parallelcomponents can be repartitioned to form inputs for the second set ofparallel components. The data can be read from a parallel data source,each part of the parallel data source being processed by a different oneof the first set of parallel components.

In another aspect, in general, the invention features a method andcorresponding software and a system for processing data. Informationcharacterizing values of a first field in records of a first data sourceand information characterizing values of a second field in records of asecond data source are accepted. Quantities characterizing arelationship between the first field and the second field are thencomputed based on the accepted information. Information relating thefirst field and the second field is presented.

Aspects of the invention can include one or more of the followingfeatures.

The information relating the first field and the second field ispresented to a user.

The first data source and the second data source are either the samedata source, or are separate data sources. Either or both of the datasource or sources can be a database table, or a file.

The quantities characterizing the relationship include quantitiescharacterizing joint characteristics of the values of the first fieldand of the second field.

The information characterizing the values of the first field (orsimilarly of the second field) includes information characterizing adistribution of values of that field. Such information may be stored ina data structure, such as a “census” data structure. The informationcharacterizing the distribution of values of the first field can includemultiple data records, each associating a different value and acorresponding number of occurrences of that value in the first field inthe first data source. Similarly, information characterizing thedistribution of values of the second field can include multiple recordsof the same or similar format.

The information characterizing the distribution of values of the firstfield and of the second field is processed to compute quantities relatedto a multiple different categories of co-occurrence of values.

The quantities related to the categories of co-occurrence of valuesinclude multiple data records, each associated with one of thecategories of co-occurrence and including a number of different valuesin the first and the second fields that are in that category.

Information characterizing a distribution of values in a “join” of thefirst data source and the second data source on the first field and thesecond field, respectively, is computed. This computation can includecomputing quantities related to a plurality of categories ofco-occurrence of values. Examples of such categories include values thatoccur at least once in one of the first and the second fields but not inthe other of the fields, values that occur exactly once in each of thefirst and the second fields, values that occur exactly once in one ofthe first and the second fields and more than once in the other of thefields, and values that occur more than once in each of the first andthe second fields.

The steps of accepting information characterizing values and computingquantities characterizing joint characteristics of the values arerepeated for multiple different pairs of fields, one of field from thefirst data source and the other field from the second data source.Information relating the fields of one or more of the plurality of pairsof fields can then be presented to the user.

Presenting the information relating the fields of one or more of thepairs of fields includes identifying candidate types of relationships offields. Examples of such types of relationships of fields include aprimary key and foreign key relationship and a common domainrelationship.

In another aspect, in general, the invention features a method andcorresponding software and a system for processing data. A plurality ofsubsets of fields of data records of a data source are identified.Co-occurrence statistics are determined for each of the plurality ofsubsets. One or more of the plurality of subsets is identified as havinga functional relationship among the fields of the identified subset.

Aspects of the invention can include one or more of the followingfeatures.

At least one of the subsets of fields is a subset of two fields.

Identifying one or more of the plurality of subsets as having afunctional relationship among the fields of the identified subsetincludes identifying one or more of the plurality of subsets as havingone of a plurality of possible predetermined functional relationships.

Determining the co-occurrence statistics includes forming data elementseach identifying a pair of fields and identifying a pair of valuesoccurring in the pair of fields in one of the data records.

Determining the co-occurrence statistics includes partitioning the datarecords into parts, the data records having a first field and a secondfield, determining a quantity based on a distribution of values thatoccur in the second field of one or more records in a first of theparts, the one or more records having a common value occurring in afirst field of the one or more records, and combining the quantity withother quantities from records in other of the parts to generate a totalquantity.

Identifying one or more of the plurality of subsets as having afunctional relationship among the fields of the identified subsetincludes identifying a functional relationship between the first andsecond fields based on the total quantity.

The parts are based on values of the first field and of the secondfield.

The parts are processed using separate ones of a set of parallelcomponents.

Identifying one or more of the plurality of subsets as having afunctional relationship among the fields of the identified subsetincludes determining a degree of match to the functional relationship.

The degree of match includes a number of exceptional records that arenot consistent with the functional relationship.

The functional relationship includes a mapping of at least some of thevalues of a first field onto at least some of the values of a secondfield.

The mapping can be, for example, a many-to-one mapping, a one-to-manymapping, or a one-to-one mapping.

The method further includes filtering the plurality of subsets based oninformation characterizing values in fields of the plurality of subsets.

The data records include records of one or more database tables.

Aspects of the invention can include one or more of the followingadvantages.

Aspects of the invention provide advantages in a variety of scenarios.For example, in developing an application, a developer may use an inputdata set to test the application. The output of the application runusing the test data set is compared against expected test results, orinspected manually. However, when the application is run using arealistic “production data,” the results may be usually too large to beverified by inspection. Data profiling can be used to verify theapplication behavior. Instead of inspecting every record produced byrunning the application using production data, a profile of the outputis inspected. The data profiling can detect invalid or unexpectedvalues, as well as unexpected patterns or distributions in the outputthat could signal an application design problem.

In another scenario, data profiling can be used as part of a productionprocess. For example, input data that is part of a regular product runcan be profiled. After the data profiling has finished, a processingmodule can load the profiling results and verify that the input datameets certain quality metrics. If the input data looks bad, the productrun can be cancelled and the appropriate people alerted.

In another scenario, a periodic audit of a large collection of data(e.g., hundreds of database tables in multiple sets of data) can beperformed by profiling the data regularly. For example, data profilingcan be performed every night on a subset of the data. The data that isprofiled can be cycled such that all of the data is profiled, e.g., oncea quarter so that every database table will be profiled four times ayear. This provides an historic data quality audit on all of the datathat can be referred to later, if necessary.

The data profiling can be performed automatically. For example, the dataprofiling can be performed from a script (e.g., a shell script) andintegrated with other forms of processing. Results of the data profilingcan be automatically published, e.g., in a form that can be displayed ina web browser, without having to manually post-process the results orrun a separate reporting application.

Operating on information characterizing values of the records in thedata sources rather than necessarily operating directly on the recordsof the data sources themselves can reduce the amount of computationconsiderably. For example, using census data rather than the raw datarecords reduces the complexity of computing characteristics of a join ontwo fields from being of the order of the product of the number of datarecords in the two data sources to being of the order of the product ofthe number of unique values in the two data sources.

Profiling the data without maintaining a copy of the data outside thedata source can avoid potential for errors associated with maintainingduplicate copies and avoids using extra storage space for a copy of thedata.

The operations may be parallelized according to data value, therebyenabling efficient distributed processing.

Quantities characterizing a relationship between fields can provide anindication of which fields may be related by different types ofrelationships. The user may then be able to examine the data moreclosely to determine whether the fields truly form that type ofrelationship.

Determining co-occurrence statistics for each of a plurality of subsetsof fields of data records of a data source enables efficientidentification of potential functional relationships among the fields.

Aspects of the invention can be useful in profiling data sets with whichthe user is not familiar. The information that is automaticallydetermined, or which is determined in cooperation with the user, can beused to populate metadata for the data sources, which can then be usedfor further processing.

Other features and advantages of the invention are apparent from thefollowing description, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a system that includes a data profilingmodule.

FIG. 2 is a block diagram that illustrates the organization of objectsin a metadata store used for data profiling.

FIG. 3 is a profiling graph for the profiling module.

FIG. 4 is a tree diagram of a hierarchy for a type object used tointerpret a data format.

FIGS. 5A-C are diagrams that illustrates sub-graphs implementing themake census component, analyze census component, and make samplescomponent of the profiling graph.

FIG. 6 is a flowchart for a rollup procedure.

FIG. 7 is a flowchart for a canonicalize procedure.

FIGS. 8A-C are example user interface screen outputs showing profilingresults.

FIG. 9 is a flowchart of an exemplary profiling procedure.

FIG. 10 is a flowchart of an exemplary profiling procedure.

FIGS. 11A-B are two examples of a join operation performed on recordsfrom two pairs of fields.

FIGS. 12A-B are two examples of a census join operation on censusrecords from two pairs of fields.

FIG. 13 is an example of extended records used to perform a singlecensus join operation on two pairs of fields.

FIG. 14 is an extend component used to generate extended records.

FIGS. 15A-C are graphs used to perform joint-field analysis.

FIG. 16 is an example table with fields having a functional dependencyrelationship.

FIG. 17 is a graph used to perform functional dependency analysis.

DESCRIPTION 1 Overview

Referring to FIG. 1, a data processing system 10 includes a profilingand processing subsystem 20, which is used to process data from datasources 30 and to update a metadata store 112 and a data store 124 in adata storage subsystem 40. The stored metadata and data is thenaccessible to users using an interface subsystem 50.

Data sources 30 in general includes a variety of individual datasources, each of which may have unique storage formats and interfaces(for example, database tables, spreadsheet files, flat text files, or anative format used by a mainframe 110). The individual data sources maybe local to the profiling and processing sub-system 20, for example,being hosted on the same computer system (e.g., file 102), or may beremote to the profiling and processing sub-system 20, for example, beinghosted on a remote computer (e.g., mainframe 110) that is accessed overa local or wide area data network.

Data storage sub-system 40 includes a data store 124 as well as ametadata store 112. Metadata store 112 includes information related todata in data sources 30 as well as information about data in data store124. Such information can include record formats as well asspecifications for determining the validity of field values in thoserecords (validation specifications).

The metadata store 112 can be used to store initial information about adata set in data sources 30 to be profiled, as well as informationobtained about such a data set, as well as data sets in data store 124derived from that data set, during the profiling process. The data store124 can be used to store data, which has been read from the data sources30, optionally transformed using information derived from dataprofiling.

The profiling and processing subsystem 20 includes a profiling module100, which reads data directly from a data source without necessarilylanding a complete copy of the data to a storage medium before profilingin units of discrete work elements such as individual records.Typically, a record is associated with a set of data fields, each fieldhaving a particular value for each record (including possibly a nullvalue). The records in a data source may have a fixed record structurein which each record includes the same fields. Alternatively, recordsmay have a variable record structure, for example, including variablelength vectors or conditional fields. In the case of variable recordstructure, the records are processed without necessarily storing a“flattened” (i.e., fixed record structure) copy of the data prior toprofiling.

When first reading data from a data source, the profiling module 100typically starts with some initial format information about records inthat data source. (Note that in some circumstances, even the recordstructure of the data source may not be known). The initial informationabout records can include the number of bits that represent a distinctvalue (e.g., 16 bits (=2 bytes)) and the order of values, includingvalues associated with record fields and values associated with tags ordelimiters, and the type of value (e.g., string, signed/unsignedinteger) represented by the bits. This information about records of adata source is specified in a data manipulation language (DML) file thatis stored in a metadata store 112. The profiling module 100 can usepredefined DML files to automatically interpret data from a variety ofcommon data system formats (e.g., SQL tables, XML files, CSV files) oruse a DML file obtained from the metadata store 112 describing acustomized data system format.

Partial, possibly inaccurate, initial information about records of adata source may be available to the profiling and processing subsystem20 prior to the profiling module 100 initial reading of the data. Forexample, a COBOL copy book associated with a data source may beavailable as stored data 114, or entered by a user 118 through a userinterface 116. Such existing information is processed by a metadataimport module 115 and stored in the metadata store 112 and/or used todefine the DML file used to access the data source.

As the profiling module 100 reads records from a data source, itcomputes statistics and other descriptive information that reflect thecontents of the data set. The profiling module 100 then writes thosestatistics and descriptive information in the form of a “profile” intothe metadata store 112 which can then be examined through the userinterface 116 or any other module with access to the metadata store 112.The statistics in the profile preferably include a histogram of valuesin each field, maximum, minimum, and mean values, and samples of theleast common and most common values.

The statistics obtained by reading from the data source can be used fora variety of uses. Such uses can include discovering the contents ofunfamiliar data sets, building up a collection of metadata associatedwith a data set, examining third-party data before purchasing or usingit, and implementing a quality control scheme for collected data.Procedures for using the data processing system 10 to perform such tasksare described in detail below.

The metadata store 112 is able to store validation informationassociated with each profiled field, for example as a validationspecification that encodes the validation information. Alternatively,the validation information can be stored in an external storage locationand retrieved by the profiling module 100. Before a data set isprofiled, the validation information may specify a valid data type foreach field. For example, if a field is a person's “title”, a defaultvalid value may be any value that is a “string” data type. A user mayalso supply valid values such as “Mr.”, “Mrs.” and “Dr.” prior toprofiling the data source so that any other value read by the profilingmodule 100 would be identified as invalid. Information obtained from aprofiling run can also be used by a user to specify valid values for aparticular field. For example, the user may find that after profiling adata set the values “Ms.” and “Msr.” appear as common values. The usermay add “Ms.” as a valid value, and map the value “Msr.” to the value“Mrs.” as a data cleaning option. Thus, the validation information caninclude valid values and mapping information to permit cleaning ofinvalid values by mapping them onto valid values. The profiling of adata source may be undertaken in an iterative manner as more informationabout the data source is discovered through successive profiling runs.

The profiling module 100 can also generate executable code to implementother modules that can access the profiled data systems. For example, aprocessing module 120 can include code generated by the profiling module100. An example of such code might map a value “Msr.” to “Mrs.” as partof the access procedure to the data source. The processing module 120may run in the same runtime environment as the profiling module 100, andpreferably can communicate with the metadata store 112 to access aprofile associated with a data set. The processing module 120 can readthe same data formats as the profiling module 100 (e.g., by obtainingthe same DML file from the metadata store 112). The processing module120 can use the data set profile to obtain values used to validate orclean incoming records before storing them in a data store 124.

Similar to the profiling module 100, the processing module 120 alsoreads data directly from a data system in units of discrete workelements. This “data flow” of work elements has the benefit of allowingthe data profiling to be performed on large data sets withoutnecessarily copying data to local storage (e.g., a disk drive). Thisdata flow model, described in more detail below, also allows complexdata transformations to be performed by a processing module without thesource data being first copied to a staging area, potentially savingstorage space and time.

2 Metadata Store Organization

The profiling module 100 uses the metadata store 112 to organize andstore various metadata and profiling preferences and results in dataobjects. Referring to FIG. 2, the metadata store 112 may store a groupof profile setup objects 201, each for information related to aprofiling job, a group of data set objects 207, each for informationrelated to a data set, and a group of DML files 211, each describing aparticular data format. A profile setup object contains preferences fora profiling run executed by the profiling module 100. A user 118 canenter information used to create a new profile setup object or select apre-stored profile setup object 200.

The profile setup object 200 contains a reference 204 to a data setobject 206. A data set setup object 206 contains a data set locator 202which enables the profiling module 100 to locate data to be profiled onone or more data systems accessible within the runtime environment. Thedata set locator 202 is typically a path/filename, URL, or a list ofpath/filenames and/or URLs for a data set spread over multiplelocations. The data set object 206 can optionally contain a reference208 to one or more DML files 210.

The DML file(s) 210 may be pre-selected based on knowledge about theformat of data in a data set, or may be specified at runtime by a user.The profiling module 100 can obtain an initial portion of the data setand present to the user over the user interface 116 an interpretation ofthe initial portion based on a default DML file. The user may thenmodify the default DML file specification based on an interactive viewof the interpretation. More than one DML file may be referenced if thedata set includes data with multiple formats.

The data set object 206 contains a reference 212 to a set of fieldobjects 214. There is one field object for each field within the recordsof the data set to be profiled. Upon completion of a profiling runperformed by the profiling module 100, a data set profile 216 iscontained within the data set object 206 corresponding to the data setthat was profiled. The data set profile 216 contains statistics thatrelate to the data set, such as total number of records and total numberof valid/invalid records.

A field object 218 can optionally contain validation information 220that can be used by the profiling module 100 to determine valid valuesfor the corresponding field, and specify rules for cleaning invalidvalues (i.e., mapping invalid values onto valid values). The fieldobject 218 also contains a field profile 222, stored by the profilingmodule 100 upon completion of a profiling run, which contains statisticsthat relate to the corresponding field, such as numbers of distinctvalues, null values, and valid/invalid values. The field profile 222 canalso include sample values such as maximum, minimum, most common, andleast common values. A complete “profile” includes the data set profile216 and field profiles for all of the profiled fields.

Other user preferences for a profiler run can be collected and stored inthe profile setup object 200, or in the data set object 206. Forexample, the user can select a filter expression which can be used tolimit the fields or number of values profiled, including profiling arandom sample of the values (e.g., 1%).

3 Runtime Environment

The profiling module 100 executes in a runtime environment that allowsdata from the data source(s) to be read and processed as a flow ofdiscrete work elements. The computations performed by the profilingmodule 100 and processing module 120 can be expressed in terms of dataflow through a directed graph, with components of the computations beingassociated with the vertices of the graph and data flows between thecomponents corresponding to links (arcs, edges) of the graph. A systemthat implements such graph-based computations is described in U.S. Pat.No. 5,966,072, EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS. Graphs madein accordance with this system provide methods for getting informationinto and out of individual processes represented by graph components,for moving information between the processes, and for defining a runningorder for the processes. This system includes algorithms that chooseinterprocess communication methods (for example, communication pathsaccording to the links of the graph can use TCP/IP or UNIX domainsockets, or use shared memory to pass data between the processes).

The runtime environment also provides for the profiling module 100 toexecute as a parallel process. The same type of graphic representationdescribed above may be used to describe parallel processing systems. Forpurposes of this discussion, parallel processing systems include anyconfiguration of computer systems using multiple central processingunits (CPUs), either local (e.g., multiprocessor systems such as SMPcomputers), or locally distributed (e.g., multiple processors coupled asclusters or MPPs), or remotely, or remotely distributed (e.g., multipleprocessors coupled via LAN or WAN networks), or any combination thereof.Again, the graphs will be composed of components (graph vertices) andflows (graph links). By explicitly or implicitly replicating elements ofthe graph (components and flows), it is possible to representparallelism in a system.

A flow control mechanism is implemented using input queues for the linksentering a component. This flow control mechanism allows data to flowbetween the components of a graph without being written to non-volatilelocal storage, such as a disk drive, which is typically large but slow.The input queues can be kept small enough to hold work elements involatile memory, typically smaller and faster than non-volatile memory.This potential savings in storage space and time exists even for verylarge data sets. Components can use output buffers instead of, or inaddition to, input queues.

When two components are connected by a flow, the upstream componentsends work elements to the downstream component as long as thedownstream component keeps consuming the work elements. If thedownstream component falls behind, the upstream component will fill upthe input queue of the downstream component and stop working until theinput queue clears out again.

Computation graphs can be specified with various levels of abstraction.So a “sub-graph” containing components and links can be representedwithin another graph as a single component, showing only those linkswhich connect to the rest of the graph.

4 Profiling Graph

Referring to FIG. 3, in a preferred embodiment, a profiling graph 400performs computations for the profiling module 100. An input data setcomponent 402 represents data from potentially several types of datasystems. The data systems may have different physical media types (e.g.,magnetic, optical, magneto-optical) and/or different data format types(e.g., binary, database, spreadsheet, ASCII string, CSV, or XML). Theinput data set component 402 sends a data flow into a make censuscomponent 406. The make census component 406 conducts a “census” of thedata set, creating a separate census record for each unique field/valuepair in the records that flow into the component. Each census recordincludes a count of the number of occurrences of the unique field/valuepair for that census record.

The make census component 406 has a cleaning option which can map a setof invalid values onto valid values according to validation informationstored in a corresponding field object. The cleaning option can alsostore records having fields containing invalid values in a locationrepresented by an invalid records component 408. The invalid records canthen be examined, for example, by a user wanting to determine the sourceof an invalid value.

In the illustrated embodiment, the census records flowing out of themake census component 406 are stored in a file represented by the censusfile component 410. This intermediate storage of census records may, insome cases, increase efficiency for multiple graph components accessingthe census records. Alternatively, the census records can flow directlyfrom the make census component 406 to an analyze census component 412without being stored in a file.

The analyze census component 412 creates a histogram of values for eachfield and performs other analyses of the data set based on the censusrecords. In the illustrated embodiment, the field profiles component 414represents an intermediate storage location for the field profiles. Aload metadata store component 416 loads the field profiles and otherprofiling results into the corresponding objects in the metadata store112.

The user interface 116 allows a user to browse through the analyzeddata, for example, to see histograms or common values in fields. A“drill-down” capability is provided, for example, to view specificrecords that are associated with a bar in a histogram. The user can alsoupdate preferences through the user interface 116 based on results ofthe profiling.

The make samples component 418 stores a collection of sample records 420representing a sampling of records associated with a value shown on theuser interface 116 (e.g., associated with a bar in a histogram). Thephase break line 422 represents two phases of execution in the graph400, such that the components on the right side of the line beginexecution after all the components on the left side of the line finishexecution. Therefore, the make samples component 418 executes after theanalyze census component 412 finishes storing results in the fieldprofiles component 414. Alternatively, sample records can be retrievedfrom a recorded location in the input data set 402.

The profiling module 100 can be initiated by a user 118 or by anautomated scheduling program. Upon initiation of the profiling module100, a master script (not shown) collects any DML files and parametersto be used by the profiling graph 400 from the metadata store 112.Parameters can be obtained from objects such as the profile setup object200, the data set object 206, and the field objects 218. If necessary,the master script can create a new DML file based on informationsupplied about the data set to be profiled. For convenience, the masterscript can compile the parameters into a job file. The master script maythen execute the profiling graph 400 with the appropriate parametersfrom the job file, and present a progress display keeping track of thetime elapsed and estimating time remaining before the profiling graph400 completes execution. The estimated time remaining is calculatedbased on data (e.g., work elements) that is written to the metadatastore 112 as the profiling graph 400 executes.

4.1 Data Format Interpretation

An import component implements the portion of the profiling module 100that can interpret the data format of a wide variety of data systems.The import component is configured to directly interpret some dataformats without using a DML file. For example, the import component canread data from a data system that uses structured query language (SQL),which is an ANSI standard computer language for accessing andmanipulating databases. Other data formats that are handled without useof a DML file are, for example, text files formatted according to an XMLstandard or using comma-separated values (CSV).

For other data formats the import component uses a DML file specified inthe profile setup object 200. A DML file can specify various aspects ofinterpreting and manipulating data in a data set. For example, a DMLfile can specify the following for a data set:

-   -   type object—defines a correspondence between raw data and the        values represented by the raw data.    -   key specifier—defines ordering, partitioning, and grouping        relationships among records.    -   expression—defines a computation using values from constants,        the fields of data records, or the results of other expressions        to produce a new value.    -   transform function—defines collections of rules and other logic        used to produce one or more outputs records from zero or more        input records.    -   package—provides a convenient way of grouping type objects,        transform functions, and variables that can be used by a        component to perform various tasks.

A type object is the basic mechanism used to read individual workelements (e.g., individual records) from raw data in a data system. Theruntime environment provides access to a physical computer-readablestorage medium (e.g., a magnetic, optical, or magneto-optical medium) asa string of raw data bits (e.g., mounted in a file system or flowingover a network connection). The import component can access a DML fileto determine how to read and interpret the raw data in order to generatea flow of work elements.

Referring to FIG. 4, a type object 502 can be, for example, a base type504 or a compound type 506. A base type object 504 specifies how tointerpret a string of bits (of a given length) as a single value. Thebase type object 504 includes a length specification indicating thenumber of raw data bits to be read and parsed. A length specificationcan indicate a fixed length, such as a specified number of bytes, or avariable length, specifying a delimiter (e.g., a specific character orstring) at the end of the data, or a number of (potentially variablelength) characters to be read.

A void type 514 represents a block of data whose meaning or internalstructure is unnecessary to interpret (e.g., compressed data that willnot be interpreted until after it is decompressed). The length of a voidtype 514 is specified in bytes. A number type 516 represents a numberand is interpreted differently if the number is designated an integer524, real 526, or decimal 528, according to various encodings that arestandard or native to a particular CPU. A string type 518 is used tointerpret text with a specified character set. Date 520 and datetime 522types are used to interpret a calendar date and/or time with a specifiedcharacter set and other formatting information.

A compound type 506 is an object made up of multiple sub-objects whichare themselves either base or compound types. A vector type 508 is anobject containing a sequence of objects of the same type (either a baseor compound type). The number of sub-objects in the vector (i.e., thelength of the vector) can be indicated by a constant in the DML file orby a rule (e.g., a delimiter indicating the end of the vector) enablingprofiling of vectors with varying lengths. A record type 510 is anobject containing a sequence of objects, each of which can be adifferent base or compound type. Each object in the sequence correspondsto a value associated with a named field. Using a record type 510, acomponent can interpret a block of raw data to extract values for all ofthe fields of a record. A union type 512 is an object similar to arecord type 510 except that objects corresponding to different fieldsmay interpret the same raw data bits as different values. The union type512 provides a way to have several interpretations of the same raw data.

The DML file also enables profiling of data with custom data types. Auser can define a custom type object by supplying a type definition interms of other DML type objects, either base or compound. A custom typeobject can then be used by the profiling module 100 to interpret datawith a non-standard structure.

The DML file also enables profiling of data with a conditionalstructure. Records may only include some fields based on valuesassociated with other fields. For example, a record may only include thefield “spouse” if the value of the field “married” is “yes.” The DMLfile includes a rule for determining whether a conditional field existsfor a given record. If the conditional field does exist in a record, thevalue of the field can be interpreted by a DML type object.

The import component can be used by graphs to efficiently handle varioustypes of record structures. The ability of the import component tointerpret records with variable record structure such as conditionalrecords or variable length vectors enables graphs to process such datawithout the need to first flatten such data into fixed length segments.Another type of processing that can be performed by graphs using theimport component is discovery of relationships between or among parts ofthe data (e.g., across different records, tables, or files). Graphs canuse a rule within the import component to find a relationship between aforeign key or field in one table to a primary key or field in anothertable, or to perform functional dependency calculations on parts of thedata.

4.2 Statistics

Referring to FIG. 5A, a sub-graph 600 implementing one embodiment of themake census component 406 includes a filter component 602 that passes aportion of incoming records based on a filter expression stored in theprofile setup object 200. The filter expression may limit the fields ornumber of values profiled. An example of a filter expression is one thatlimits profiling to a single field of each incoming record (e.g.,“title”). Another optional function of the filter component 602 is toimplement the cleaning option described above, sending a sample ofinvalid records to the invalid records component 408. Records flowingout of the filter component 602 flow into a local rollup sequence statscomponent 604 and a partition by round-robin component 612.

The ability of the profiling graph 400 (and other graphs and sub-graphs)to run in parallel on multiple processors and/or computers, and theability of the profiling graph 400 to read a parallel data set storedacross multiple locations, are implicitly represented in the sub-graph600 by line thicknesses of the components and symbols on the linksbetween components. The thick border of components representing storagelocations such as the input data set component 402 indicates that it mayoptionally be a parallel data set. The thick border of the processcomponents such as the filter component 602 indicates that the processmay optionally be running in multiple partitions with each partitionrunning on a different processor or computer. The user can indicatethrough the user interface 116 whether to run the optionally parallelgraph components in parallel or serially. A thin border indicates that adata set or process is serial.

The local rollup sequence stats component 604 computes statisticsrelated to the sequential characteristics of the incoming records. Forexample, the component 604 may count the number of sequential pairs ofrecords that have values for a field that increase, decrease, orincrement by 1. In the case of parallel execution, the sequencestatistics are calculated for each partition separately. A rollupprocess involves combining information from multiple input elements(sequence statistics for the rollup process performed by this component604) and producing a single output element in place of the combinedinput elements. A gather link symbol 606 represents a combination or“gathering” of the data flows from any multiple partitions of a parallelcomponent into a single data flow for a serial component. The globalrollup sequence stats combines the “local” sequence statistics frommultiple partitions into a single “global” collection of sequencestatistics representing records from all of the partitions. Theresulting sequence statistics may be stored in a temporary file 610.

FIG. 6 is a flowchart of an example of a process 700 for performing arollup process, including the rollup processes performed by the localrollup sequence stats component 604 and the global rollup sequence statscomponent 608. The process 700 begins by receiving 702 an input element.The process 700 then updates 704 information being compiled, anddetermines 706 whether there are any more elements to be compiled. Ifthere are more elements, the process 700 receives 702 the next elementand updates 704 the information accordingly. When there are no moreelements, the process 700 finalizes 708 the output element based on thecompiled rollup information. A rollup process can be used to consolidatea group of elements into a single element, or to determine aggregateproperties of a group of elements (such as statistics of values in thoseelements).

The partition by round-robin component 612 takes records from the singleor multiple partitions of the input data set 402 and re-partitions therecords among a number of parallel processors and/or computers (e.g., asselected by the user) in order to balance the work load among theprocessors and/or computers. A cross-connect link symbol 614 representsthe re-partitioning of the data flows (performed by the linked component612).

The canonicalize component 616 takes in a flow of records and sends outa flow of census elements containing a field/value pair representingvalues for each field in an input record. (An input record with tenfields yields a flow of ten census elements.) Each value is convertedinto a canonical (i.e., according to a pre-determined format) humanreadable string representation. Also included in the census element areflags indicating whether the value is valid and whether the value isnull (i.e., corresponds to a pre-determined “null” value). The censuselements flow into a local rollup field/value component which (for eachpartition) takes occurrences of the same value for the same field andcombines them into one census element including a count of the number ofoccurrences. Another output of the canonicalize component 616 is a countof the total number of fields and values, which are gathered for all thepartitions and combined in a rollup total counts component 618. Thetotal counts are stored in a temporary file 620 for loading into thedata set profile 216.

FIG. 7 is a flowchart of an example of a process 710 performed by thecanonicalize component that can handle conditional records, which maynot all have the same fields, to produce a flow of census elementscontaining field/value pairs. The process 710 performs a nested loopwhich begins with getting 712 a new record. For each record, the process710 gets 714 a field in that record and determines 716 whether thatfield is a conditional field. If the field is conditional, the process710 determines 718 whether that field exists for that record. If thefield does exist, the process 710 canonicalizes 720 the record's valuefor that field and produces a corresponding output element containing afield/value pair. If the field does not exist, the process 710 proceedsto determine 722 whether there is another field or to determine 724whether there is another record. If the field is not conditional, theprocess 710 canonicalizes 720 the record's for that field (includingpossibly a null value) and proceeds to the next field or record.

The partition by field/value component 624 re-partitions the censuselements by field and value so that the rollup process performed in theglobal rollup field/value component 626 can add the occurrencescalculated in different partitions to produce a total occurrences countin a single census element for each unique field/value pair containedwithin the profiled records. The global rollup field/value component 626processes these census elements in potentially multiple partitions for apotentially parallel file represented by the census file component 410.

FIG. 5B is a diagram that illustrates a sub-graph 630 implementing theanalyze census component 412 of the profiling graph 400. A partition byfield component 632 reads a flow of census elements from the census filecomponent 410 and re-partitions the census elements according to a hashvalue based on the field such that census records with the same field(but different values) are in the same partition. The partition in tostring, number, date component 634 further partitions the censuselements according to the type of the value in the census element.Different statistics are computed (using a rollup process) for valuesthat are strings (in the rollup string component 636), numbers (in therollup number component 638), or dates/datetimes (in the rollup datecomponent 640). For example, it may be appropriate to calculate averageand standard deviation for a number, but not for a string.

The results are gathered from all partitions and the computehistogram/decile info component 642 provides information useful forconstructing histograms (e.g., maximum and minimum values for eachfield) to a compute buckets component 654, and information useful forcalculating decile statistics (e.g., the number of values for eachfield) to a compute deciles component 652. The components of thesub-graph 630 that generate the histograms and decile statistics (belowthe phase break line 644) execute after the compute histogram/decileinfo component 642 (above the phase break line 644) finishes execution.

The sub-graph 630 constructs a list of values at decile boundaries(e.g., value larger than 10% of values, 20% of values, etc.) by: sortingthe census elements by value within each partition (in the sortcomponent 646), re-partitioning the census elements according to thesorted value (in the partition by values component 648), and merging theelements into a sorted (serial) flow into the compute deciles component652. The compute deciles component 652 counts the sorted values for eachfield in groups of one tenth of the total number of values in that fieldto find the values at the decile boundaries.

The sub-graph 630 constructs histograms for each field by: calculatingthe values defining each bracket of values (or “bucket”), countingvalues within each partition falling in the same bucket (in the localrollup histogram component 656), counting values within each bucket fromall the partitions (in the global rollup histogram component 658). Acombine field profile parts component 660 then collects all of theinformation for each field profile, including the histograms, decilestatistics, and the sequence statistics from the temporary file 610,into the field profiles component 414. FIG. 5C is a diagram thatillustrates a sub-graph 662 implementing the make samples component 418of the profiling graph 400. As in the sub-graph 600, a partition byround-robin component 664 takes records from the single or multiplepartitions of the input data set 402 and re-partitions the records amonga number of parallel processors and/or computers in order to balance thework load among the processors and/or computers.

A lookup and select component 666 uses information from the fieldprofiles component 414 to determine whether a record corresponds to avalue shown on the user interface 116 that can be selected by a user fordrill-down viewing. Each type of value shown in the user interface 116corresponds to a different “sample type.” If a value in a recordcorresponds to a sample type, the lookup and select component 666computes a random selection number that determines whether the record isselected to represent a sample type.

For example, for a total of five sample records of a particular sampletype, if the selection number is one of the five largest seen so far (ofa particular sample type within a single partition) then thecorresponding record is passed as an output along with informationindicating what value(s) may correspond to drill-down viewing. With thisscheme, the first five records of any sample type are automaticallypassed to the next component as well as any other records that have oneof the five largest selection numbers seen so far.

The next component is a partition by sample type component 668 whichre-partitions the records according to sample type so that the sortcomponent 670 can sort by selection number within each sample type. Thescan component 672 then selects the five records with the largestselection numbers (among all the partitions) for each sample type. Thewrite/link sample component 674 then writes these sample records to asample records file 420 and links the records to the correspondingvalues in the field profiles component 414.

The load metadata store component 416 loads the data set profile fromthe temporary file component 620 into a data set profile 216 object inthe metadata store 112, and loads each of the field profiles from thefield profiles component 414 into a field profile 222 object in themetadata store 112. The user interface 116 can then retrieve theprofiling results for a data set and display it to a user 118 on ascreen of produced by the user interface 116. A user can browse throughthe profile results to see histograms or common values for fields. Adrill-down capability may be provided, for example, to view specificrecords that are associated with a bar in a histogram.

FIG. 8A-C are example user interface screen outputs showing profilingresults. FIG. 8A shows results from a data set profile 216. Varioustotals 802 are shown for the data set as a whole, along with a summary804 of properties associated with the profiled fields. FIGS. 8B-C showresults from an exemplary field profile 222. A selection of values, suchas most common values 806, and most common invalid values 808, aredisplayed in various forms including: the value itself as a humanreadable string 810, a total count of occurrences of the value 812,occurrences as a percentage of the total number of values 814, and a barchart 816. A histogram of values 818 is displayed showing a bar for eachof multiple buckets spanning the range of values, including buckets withcounts of zero. The decile boundaries 820 are also displayed.

5 Examples 5.1 Data Discovery

FIG. 9 shows a flowchart for an example of a procedure 900 for profilinga data set to discover its contents before using it in another process.The procedure 900 can be performed automatically (e.g., by a schedulingscript) or manually (e.g., by a user at a terminal). The procedure 900first identifies 902 a data set to be profiled on one or more datasystems accessible within the runtime environment. The procedure 900 maythen optionally set a record format 904 and set validation rules 906based on supplied information or existing metadata. For some types ofdata, such as a database table, a default record format and validationrules may be used. The procedure 900 then runs 908 a profile on the dataset (or a subset of the data set). The procedure 900 can refine 910 therecord format, or refine 912 the validation rules based on the resultsof the initial profile. If any profiling options have changed, theprocedure 900 then decides 914 whether to run another profile on thedata using the new options, or to process 916 the data set if enoughinformation about the data set has been obtained from the (possiblyrepeated) profiling. The process would read directly from the one ormore data systems using the information obtained from the profiling.

5.2 Quality Testing

FIG. 10 shows a flowchart for an example of a procedure 1000 forprofiling a data set to test its quality before transforming and loadingit into a data store. The procedure 1000 can be performed automaticallyor manually. Rules for testing the quality of a data set can come fromprior knowledge of the data set, and/or from results of a profilingprocedure such as procedure 900 performed on a similar data set (e.g., adata set from the same source as the data set to be tested). Thisprocedure 1000 can be used by a business, for example, to profile aperiodic (e.g., monthly) data feed sent from a business partner beforeimporting or processing the data. This would enable the business todetect “bad” data (e.g., data with a percentage of invalid values higherthan a threshold) so it doesn't “pollute” an existing data store byactions that may be difficult to undo.

The procedure 1000 first identifies 1002 a data set to be tested on oneor more data systems accessible within the runtime environment. Theprocedure 1000 then runs 1004 a profile on the data set (or a subset ofthe data set) and performs 1006 a quality test based on results of theprofile. For example, a percentage of occurrences of a particular commonvalue in the data set can be compared with a percentage of occurrencesof the common value in a prior data set (based on a prior profilingrun), and if the percentages differ from each other by more than 10%,the quality test fails. This quality test could be applied to a value ina series of data sets that is known to occur consistently (within 10%).The procedure 1000 determines 1008 the results of the quality test, andgenerates 1010 a flag (e.g., a user interface prompt or an entry in alog file) upon failure. If the quality test is passed, the procedure1000 then reads directly from the one or more data systems andtransforms (possibly using information from the profile) and loads 1012data from the data set into a data store. For example, the procedure canthen repeat by identifying 1002 another data set.

5.3 Code Generation

The profiling module 100 can generate executable code such as a graphcomponent that can be used to process a flow of records from a data set.The generated component can filter incoming records, allowing only validrecords to flow out, similar to the cleaning option of the profilinggraph 400. For example, the user can select a profiling option thatindicates that a clean component should be generated upon completion ofa profiling run. Code for implementing the component is directed to afile location (specified by the user). The generated clean component canthen run in the same runtime environment as the profiling module 100using information stored in the metadata store 112 during the profilingrun.

6 Joint-Field Analysis

The profiling module 100 can optionally perform an analysis ofrelationships within one or more groups of fields. For example, theprofiling module 100 is able to perform an analysis between two of apair of fields, which may be in the same or in different data sets.Similarly, the profiling module is able to perform analysis on a numberof pairs of fields, for example analyzing every field in one data setwith every field in another data set, or every field in one data setwith every other field in the same data set. An analysis of two fieldsin different data sets is related to the characteristics of a joinoperation on the two data sets on those fields, as described in moredetail below.

In a first approach to joint-field analysis, a join operation isperformed on two data sets (e.g., files or tables). In another approach,described below in section 6.1, after the make census component 406generates a census file for a data set, the information in the censusfile can be used to perform the joint-field analysis between fields intwo different profiled data sets, or between fields in two differentparts of the same profiled data set (or any other data set for which acensus file exists). The result of joint-field analysis includesinformation about potential relationships between the fields.

Three types of relationships that are discovered are: a “common domain”relationship, a “joins well” relationship, and “foreign key”relationship. A pair of fields is categorized as having one of thesethree types of relationships if results of the joint-field analysis meetcertain criteria, as described below.

The joint-field analysis includes compiling information such as thenumber of records produced from a join operation performed using the twofields as key fields. FIGS. 11A-B illustrate examples of a joinoperation performed on records from two database tables. Each of Table Aand Table B has two fields labeled “Field 1” and “Field 2,” and fourrecords.

Referring to FIG. 11A, a join component 1100 compares values from a keyfield of records from Table A with values from a key field of recordsfrom Table B. For Table A, the key field is Field 1, and for Table B,the key field is Field 2. So the join component 1100 compares values1102 from Table A, Field 1 (A1) with values 1104 from Table B, Field 1(B1). The join component 1100 receives flows of input records 1110 fromthe tables, and, based on the comparison of key-field values, produces aflow of joined records 1112 forming a new joined table, Table C. Thejoin component 1100 produces a joined record that is a concatenation ofthe records with matching key-field values for each pair of matchingkey-field values in the input flows.

The number of joined records with a particular key-field value that exiton the joined output port 1114 is the Cartesian product of the number ofrecords with that key-field value in each of the inputs, respectively.In the illustrated example, the input flows of records 1110 are shownlabeled by the value of their respective key fields, and the output flowof joined records 1112 are shown labeled by the matched values. Sincetwo “X” values appear in each of the two input flows, there are four “X”values in the output flow. Records in one input flow having a key-fieldvalue that does not match with any record in the other input flow exiton “rejected” output ports 1116A and 1116B, for the Table A and Table Binput flows, respectively. In the illustrated example, a “W” valueappears on the rejected output port 1116A.

The profiling module 100 compiles statistics of joined and rejectedvalues for categorizing the relationship between two fields. Thestatistics are summarized in an occurrence chart 1118 that categorizesoccurrences of values in the two fields. An “occurrence number”represents the number of times a value occurs in a field. The columns ofthe chart correspond to occurrence numbers 0, 1, and N (where N>1) forthe first field (from Table A in this example), and the rows of thechart correspond to occurrence numbers 0, 1, and N (where N>1) for thesecond field (from Table B in this example). The boxes in the chartcontain counts associated with the corresponding pattern of occurrence:‘column occurrence number’×‘row occurrence number’. Each box containstwo counts: the number of distinct values that have that pattern ofoccurrence, and the total number of individual joined records for thosevalues. In some cases the values occur in both fields (i.e., having apattern of occurrence: 1×1, 1×N, N×1, or N×N), and in other cases thevalues occur in only one field (i.e., having a pattern of occurrence:1×0, 0×1, N×0, or 0×N). The counts are separated by a comma.

The occurrence chart 1118 contains counts corresponding to the joinedrecords 1112 and the rejected record on port 1116A. The value “W” on therejected output port 1116A corresponds to the “1, 1” counts in the boxfor the 1×0 pattern of occurrence indicating a single value, and asingle record, respectively. The value “X” corresponds to the “1, 4”counts in the box for the N×N pattern of occurrence since the value “X”occurs twice in each input flow, for a total of four joined records. Thevalue “Y” corresponds to the “1, 2” counts in the box for the 1×Npattern of occurrence since the value “Y” occurs once in the first inputflow and twice in the second input flow, for a total of two joinedrecords.

FIG. 11B illustrates an example similar to the example of FIG. 11A, butwith a different pair of key fields. For Table A, the key field is Field1, and for Table B, the key field is Field 2. So the join componentcompares values 1102 from Table A, Field 1 (A1) with values 1120 fromTable B, Field 2 (B2). This example has an occurrence chart 1122 withcounts corresponding to the flows of input records 1124 for thesefields. Similar to the example in FIG. 11A, there is a single rejectedvalue “Z” that corresponds to the “1, 1” counts in the box for the 0×1pattern of occurrence. However, in this example, there are two values,“W” and “Y,” that both have the 1×1 pattern of occurrence, correspondingto the “2, 2” counts in the fox for the 1×1 pattern of occurrence sincethere are two values, and two joined records. The value “X” correspondsto the “1, 2” counts in the box for the N×1 pattern of occurrence,indicating a single value and 2 joined records.

Various totals are calculated from the numbers in the occurrence chart.Some of these totals include the total number of distinct key-fieldvalues occurring in both Table A and Table B, the total number ofdistinct key-field values occurring in Table A, the total number ofdistinct key-field values occurring in Table B, and the total numberunique values (i.e., values occurring only in a single record of the keyfield) in each table. Some statistics based on these totals are used todetermine whether a pair of fields has one of the three types ofrelationships mentioned above. The statistics include the percentages oftotal records in a field that have distinct or unique values,percentages of total records having a particular pattern of occurrence,and the “relative value overlap” for each field. The relative valueoverlap is the percentage of distinct values occurring one field thatalso occur in the other. The criteria for determining whether a pair offields has one of the three types of relationships (which are notnecessarily mutually exclusive) are:

foreign key relationship—a first one of the fields has a high relativevalue overlap (e.g., >99%) and the second field has a high percentage(e.g., >99%) of unique values. The second field is potentially a primarykey and the second field is potentially a foreign key of the primarykey.joins well relationship—at least one of the fields has a smallpercentage (e.g., <10%) of rejected records, and the percentage ofindividual joined records having a pattern of occurrence of N×N is small(e.g., <1%).common domain relationship—at least one of the fields has a highrelative value overlap (e.g., >95%).If a pair of fields has both a foreign key and a joins well or commondomain relationship, the foreign key relationship is reported. If a pairof fields has both a joins well relationship and a common domainrelationship, but not a foreign key relationship, the joins wellrelationship is reported.

6.1 Census Join

Referring to FIG. 12A, in an alternative to actually performing a joinoperation on the tables, a census join component 1200 analyzes fieldsfrom Table A and Table B and compiles the statistics for an occurrencechart by performing a “census join” operation from census data for thetables. Each census record has a field/value pair and a count of theoccurrences of the value in the field. Since each census record has aunique field/value pair, for a given key field, the values in an inputflow of the census join component 1200 are unique. The example of FIG.12A corresponds to the join operation on the pair of key fields A1, B1(illustrated in FIG. 11A). By comparing census records corresponding tothe key fields in the join operation, with filter 1202 selecting “Field1” (A1) and filter 1204 selecting “Field 1” (B1), the census joincomponent 1200 potentially makes a much smaller number of comparisonsthan a join component 1100 that compares key fields of individualrecords from Table A and Table B. The example of FIG. 12B corresponds tothe join operation on the pair of key fields A1, B2 (illustrated in FIG.11B), with filter 1206 selecting “Field 1” (A1) and filter 1208selecting “Field 2” (B2). The selected census records 1210-1218 areshown labeled by the value for their respective field in the field/valuepair, and the count of occurrences for that value.

If the census join component 1200 finds a match between the values intwo input census records 1210-1218, the output record contains thematched value, the corresponding pattern of occurrence based on the twocounts, and a total number of records that would be generated in a joinoperation on the pair of key fields (which is just the product of thetwo counts). If no match is found for a value, the value is also outputwith a corresponding pattern of occurrence and a total number of records(which is the single count in the single input record). This informationwithin the output records of the census join component 1200 issufficient to compile all of the counts in an occurrence chart for thejoin operation.

In the example of FIG. 12A, the value “W” appears at the output with anoccurrence pattern of 1×0 and a total of 1, the value “X” appears at theoutput with an occurrence pattern of N×N and a total of 4, and the value“Y” appears at the output with an occurrence pattern of 1×N and a totalof 2. This information corresponds to the information in the occurrencechart 1118 of FIG. 11A. In the example of FIG. 12B, the value “W”appears at the output with an occurrence pattern of 1×1 and a total of1, the value “X” appears at the output with an occurrence pattern of N×1and a total of 2, the value “Y” appears at the output with an occurrencepattern of 1×1 and a value of 1, and the value “Z” appears at the outputwith an occurrence pattern of 0×1 and a value of 1. This informationcorresponds to the information in the occurrence chart 1122 of FIG. 11B.

6.2 Extended Records

A joint-field analysis for multiple field pairs in a single census joinoperation includes generating “extended records” based on the censusrecords. In the example illustrated in FIG. 13, the census joincomponent 1200 compares records for a joint-field analysis of both pairsof key fields A1, B1 and A1, B2, combining the joint-field analysisillustrated in FIGS. 12A-B. An extended record is generated from acensus records by concatenating a unique identifier for the pair of keyfields that are being joined with the value in the census record, andkeeping the same count of occurrences as the census record.

If a joint-field analysis includes results of a field being joined withmultiple other fields, then multiple extended records are generated foreach value in the that field. For example, the census record 1210corresponds to two extended records 1301-1302, with the value “W”concatenated with an identifier “A1B1” and “A1B2,” respectively. Thecensus join component 1200 handles the extended record 1301 just as itwould handle a census record with the value “WA1B1.” Likewise, thecensus record 1211 corresponds to the two extended records 1303-1304,and census record 1212 corresponds to the two extended records1305-1306.

In the joint-field analysis of FIG. 13, the field B1 is only joined withone other field (A1), so each census record 1213-1214 corresponds to asingle extended record 1307-1308, respectively. Likewise, the field B2is joined with one other field (A1), so each census record 1215-1218corresponds to a single extended record 1309-1312. Each extended recordincludes a value based on the original value concatenated with a uniquefield identifier.

Referring to FIG. 14, an extend component 1400 processes input censusrecords to generate extended records, based on join information 1401indicating which fields are being joined with which other fields in thejoint-field analysis. In this example, the join information 1401indicates that a field F₁ from census data for table T1 (having fourcensus records 1402) is being joined with four other fields: field F₁from census data for table T2 (having two census records 1404), field F₂from census data for table T2 (having two census records 1406), field F₁from census data for table T3 (having two census records 1408), andfield F₂ from census data for table T3 (having two census records 1410).A census record 1412 flowing into the extend component 1400 representsone of the four census records 1402 from census data for table T1 havingfield F₁, and value V_(i) where i=1, 2, 3, or 4. The extend component1400 generates four extended records 1413-1416 for the input censusrecord 1412.

The census join component 1200 uses unique identifiers for fieldsincluding fields in different tables having the same name. The extendedrecord 1413 has a value c(T1,F₁,T2,F₁,V_(i)) that is a concatenation ofthe original value Vi with identifiers for the fields being joined aswell as for the table (or file or other data source) from which thecensus data for the field was generated. Including the identifier forthe table enables fields having the same name to be distinguished. Theextended record 1415 that has a value c(T1,F₁,T3,F₁,V_(i)) that can bedistinguished from the value c(T1,F₁,T2,F₁,V_(i)) of the extended record1413, where both tables T2 and T3 have the same field name F₁.Alternatively, a unique number can be assigned to each field and used inplace of the field name.

6.3 Joint-Field Analysis Graphs

FIGS. 15A-B show graphs used by the profiling module 100 to perform anoptional joint-field analysis of selected fields in sources (e.g.,tables or files) within data sources 30. A user 118 selects options forprofiling and for joint-field analysis, including the option ofperforming profiling without joint-field analysis. The user 118 selectsfield pairs for joint-field analysis including two specific fieldspaired with each other, one field paired with every other field, orevery field paired with every other field. The user 118 selects anoption allow pairing of fields within the same table or file, or toallow pairing of fields only from different tables or files. Theseoptions are stored in the metadata store 112.

Referring to FIG. 15A, for each source (e.g., a table or file) of fieldsspecified in the joint-field analysis options, the graph 1500 generatesa file with prepared census data 1510 for those specified fields. Thegraph 1500 executes once for each such source included in thejoint-field analysis. A filter 1504 receives records from census data1502 generated by the make census component 406 and prepares the recordsfor joint-field analysis. The filter 1504 discards records for fieldsthat are not included in the analysis (as determined by user optionsstored in the metadata store 112). The filter 1504 also discards invalidvalues, null values, and other values not included in a meaningfulanalysis of the content of data sources (e.g., known data flags).

The values in the census data 1502 have been canonicalized by acanonicalize component 616 within the make census component 406.However, these canonicalized values may have portions that should not beused in a logical comparison of values (e.g., strings with leading ortrailing spaces or numbers with leading or trailing zeros). The user 118can select an option for these values to be compared “literally” or“logically.” If the user 118 selects “literal” comparison, then thevalues in the census records are left in the canonicalized form. If theuser 118 selects “logical” comparison, then the filter 1504 convertsvalues in the census records according to rules such as strippingleading and trailing spaces, and stripping leading and trailing zerosfor numbers.

The partition by value component 1506 re-partitions the records based onthe value in the census record. Any census records with the same valueare put into the same partition. This allows the joint-field analysis tobe run in parallel across any number partition. Since the census joincomponent 1200 only produces an output record for input records withmatching values, census records (or any extended records generated fromthem) in different partitions do not need to be compared with oneanother.

A rollup logical values component 1508 combines any census records thathave matching field/value pairs due to the conversion performed by thefilter 1504. The combined record has a count of occurrences that is thesum of the count for all of the combined records. For example, if acensus record with a field, value, count of “amount, 01.00, 5” isconverted to “amount, 1, 5” and a census record with a field, value,count of “amount, 1.0, 3” is converted to “amount, 1, 3,” then therollup logical values component 1508 combines these two convertedrecords to a single record with a field, value, count of “amount, 1, 8.”

Referring to FIG. 15B, for each pair of sources, source A and source B,having one or more fields to be compared, as specified in thejoint-field analysis options, the graph 1512 executes using the preparedcensus data A 1514 and prepared census data B 1516, each prepared bygraph 1500. Two extend components 1400 receive records from these setsof prepared census data, along with join information 1515 specifying thespecific fields in source A to be compared with specific fields insource B. Extended records flow into a census join component 1200 thatgenerates records containing values, patterns of occurrence, and countsfor occurrence charts for the fields being compared. A local rollup joinstatistics component 1518 compiles the information in these recordswithin each partition. The records in the various partitions are thengathered and complied by a global rollup join statistics component 1520that outputs a file 1522 all of the joint-field analysis statistics forthe fields in all of the pairs of sources that are analyzed. The resultsof the joint-field analysis including which of the three types ofrelationship potentially exists between various fields is loaded intothe metadata store 112 for presentation to the user 118. For example,the user 118 can select a link on the user interface 116 for a pair offields with a potential relationship and view a page on the userinterface 116 with detailed analysis results including counts from anoccurrence chart for the pair of fields.

Referring to FIG. 15C, when a joint-field analysis is performed for twofields within the same source (source C), the graph 1524 executes usingthe prepared census data C 1526 prepared by graph 1500. A single extendcomponent 1400 receives records from the set of prepared census data C1526, along with join information 1528 specifying the specific fields insource C to be compared. Extended records flow into both ports of acensus join component 1200 that generates records containing values,patterns of occurrence, and counts for occurrence charts for the fieldsbeing compared.

In the case of joint-field analysis options indicating that every fieldin source C is to be compared with every other field in source C (havingfour fields: F1, F2, F3, F4), one approach is for the join information1528 to specify twelve pairs of fields (F1-F2, F1-F3, F1-F4, F2-F1,F2-F3, F2-F4, F3-F1, F3-F2, F3-F4, F4-F1, F4-F2, F4-F3). However, sincethe same operations are performed for the pairs F1-F3 and F3-F1, someoperations are repeated. Accordingly, another approach is for the joininformation to specify only the six unique pairs F1-F2, F1-F3, F1-F4,F2-F3, F2-F4, F3-F4. In this case, the results in the output file 1530are augmented to include results for the other six field pairs byreversing the order of the fields in the analysis results for the sixpairs that were analyzed.

7 Functional Dependency Analysis

Another type of analysis that the profiling module 100 is able toperform is a test for a functional relationship between values offields. The fields tested can be from a single table that has a set offields or from a “virtual table” that includes fields from multiplesources that are related (e.g., through a join operation on the fieldsusing a common key field, as described in more detail in section 7.3).One type of functional relationship between a pair of fields is“functional dependency” where the value associated with one field of arecord can be uniquely determined by the value associated with anotherfield of the record. For example, if a database has a State field and aZip Code field, the value of the Zip Code field (e.g., 90019) determinesthe value of the State field (e.g., CA). Each value of the Zip Codefield maps onto a unique value of the State field (i.e., a “many-to-one”mapping). A functional dependency relationship can also exist among asubset of fields where the value associated with one field of a recordcan be uniquely determined by the values associated with other fields ofthe record. For example, the value of the Zip Code field can be uniquelydetermined by the values of a City field and a Street field.

The functional dependency can also be an “approximate functionaldependency” where some but not necessarily all of the values associatedwith one field map onto a unique value of another field, with apercentage of exceptions that do not map onto the unique value. Forexample, some records may have an unknown Zip Code that is indicated bya special value 00000. In this case, the value 00000 of the Zip Codefield may map onto more than one value of the State field (e.g., CA, FL,and TX). Exceptions can also occur due to records with incorrect values,or other errors. If the percentage of exceptions is smaller than apre-determined (e.g., as entered by a user) threshold, then a field maystill be determined to be functionally dependent on another field.

Referring to FIG. 16, an example table 1600 with records (rows) andfields (columns) to be tested for functional dependency or approximatefunctional dependency is shown. A Last Name field has twelve valuescorresponding to twelve records (rows 1-12). Ten of the values areunique, and two of the records have the same repeated value name_g. ACitizenship field has two unique values: US occurring eleven times andCANADA occurring once. A Zip Code field has various values eachcorresponding to one of three values CA, FL, and TX for a State field.Each value of Zip Code uniquely determines a value of State, except forthe Zip Code value 00000 that corresponds to FL in one record (row 10)and to TX in another record (row 12).

7.1 Functional Dependency Analysis Graph

FIG. 17 shows an example of a graph 1700 used by the profiling module100 to perform an optional functional dependency analysis of selectedfields in one or more sources (e.g., in a single table or file, or inmultiple tables and/or files as described in section 7.3) within datasources 30. A user 118 selects options for profiling and for functionaldependency analysis, including the option of performing profilingwithout functional dependency analysis. The user 118 may choose whichpair or pairs of fields are tested for a functional relationship. Theuser 118 selects particular fields of a data source (e.g., a table orfile), and chooses, for example, “all to selected” or “selected toselected” to determine which pairs of fields are tested or chooses “allto all” to test all pairs of fields in the data source. The user mayalso select a threshold for determining a degree of functionaldependency before deciding that a field is or is not functionallydependent on another field. For example, the user may select a thresholdfor determining how many exceptions to allow (as a percentage ofrecords). These options are stored in the metadata store 112.

For each pair of fields (f1, f2) that is to be analyzed, the graph 1700determines whether a functional dependency relationship exists, and ifso, classifies the relationship between field f1 and field f2 as: “f1determines f2”, “f2 determines f1”, “one-to-one” (a one-to-one mappingexists between f1 and f2), or “identical” (f1 has identically the samevalue as f2 in each of the records). The graph 1700 reads fieldinformation 1702 stored by the profiling module 100 to determine uniqueidentifiers for fields to be analyzed. A make pairs component 1704generates a flow of field pairs (f1, f2) using a pair of uniqueidentifiers for each of the pairs of fields to be tested. The pair (f1,f2) is an ordered pair since the relationship between f1 and f2 is notnecessarily symmetric. So both pairs (f1, f2) and (f2, f1) are includedin the flow.

A select pairs component 1706 limits the field pairs that flow to therest of the graph 1700 by selecting the field pairs chosen for analysisby the user. The select pairs component 1706 further limits the pairsthat flow to the rest of the graph based on a variety of optimizations.For example, a field is not paired with itself since such a pair isclassified as “identical” by definition. So the pairs (f1, f1), (f2,f2), . . . etc. are not included in the flow. Other optimizations mayremove one or more pairs of fields from the flow, as described in moredetail below in section 7.2.

A broadcast component 1708 broadcasts the serial flow of field pairs toeach of the partitions of a (potentially parallel) attach valuescomponent 1718, as represented by a broadcast link symbol 1710. Eachpartition of the attach values component 1718 takes as input a flow offield pairs (e.g., (LastName, Citizenship), (Zip, State), . . . etc.)and a flow of field/value pairs (e.g., (LastName, name_a), (LastName,name_b), (LastName, name_c), . . . , (Citizenship, Canada),(Citizenship, US), (Citizenship, US), . . . etc.).

To obtain the flow of field/value pairs, a filter component 1712extracts records from the input data set 402, and optionally removes aportion of the records based on a filter expression. The records flowingout of the filter component 1712 flow into a partition by round-robincomponent 1714. The partition by round-robin component 1714 takesrecords from the partitions of the input data set 402 and re-partitionsthe records among a number of parallel processors and/or computers inorder to balance the work load among the processors and/or computers.The canonicalize component 1716 (similar to the canonicalize component616 described above) takes in a flow of records and sends out a flow offield/value pair representing values for each field in an input record.As described above, each value is converted into a canonical humanreadable string representation.

The attach values component 1718 performs a series of join operations togenerate a flow of f1/f2/v1/v2 quadruples where f1 and f2 correspond toone of the field pairs received at the input, and v1 and v2 correspondsto values that are paired with those fields in a record. In the exampleof table 1600, when the Last Name field corresponds to f1 and theCitizenship field corresponds to f2, the attach value component 1718generates a flow of twelve f1/f2/v1/v2 quadruples including:(LastName/Citizenship/name_a/Canada), (LastName/Citizenship/name_b/US),. . . , (LastName/Citizenship/name_k/US),(LastName/Citizenship/name_g/US). The attach values component 1718generates similar series of f1/f2/v1/v2 quadruples for (Zip, State) andany other pairs of fields that are analyzed.

The attach values component 1718 outputs the flow of f1/f2/v1/v2quadruples into a “local rollup f1/f2/v1/v2” component 1720 which (foreach partition) accumulates multiple quadruples with the same fields andvalues f1, f2, v1, v2 and represents them as a single quadruple with acount of the number of occurrences of the quadruple in the input flow.The output flow of the “local rollup f1/f2/v1/v2” component 1720consists of quadruples with counts (or “accumulated quadruples”).

The accumulation that occurs in the “local rollup f1/f2/v1/v2” component1720 is within each partition. So it is possible that some quadrupleswith the same values of f1, f2, v1, v2 are not accumulated by thiscomponent 1720. A “partition by f1/f2” component 1721 repartitions theflow of accumulated quadruples such that quadruples with the same fieldsf1, f2 are in the same partition. A “global rollup f1/f2/v1/v2”component 1722 further accumulates the repartitioned quadruples. Theoutput flow of the “global rollup f1/f2/v1/v2” component 1722 consistsof unique accumulated quadruples. In the example of table 1600, when theZip field corresponds to f1 and the State field corresponds to f2, thecombined effect of the components 1720-1722 generates the following sixaccumulated quadruples: (Zip/State/90019/CA, 4), (Zip/State/90212/CA,2), (Zip/State/33102/FL, 3), (Zip/State/00000/FL, 1),(Zip/State/77010/TX, 1), (Zip/State/00000/TX, 1). When the State fieldcorresponds to f1 and the Zip field corresponds to f2, the combinedeffect of the components 1720-1722 generates the following sixaccumulated quadruples: (State/Zip/CA/90019, 4), (State/Zip/CA/90212,2), (State/Zip/FL/33102, 3), (State/Zip/FL/00000, 1),(State/Zip/TX/77010, 1), (State/Zip/TX/00000, 1).

To prepare to test for a functional dependency relationship between apair of fields, a “global rollup f1/f2/v1” component 1724 combinesaccumulated quadruples that have both fields f1, f2 and the first valuev1 in common. In producing an output element, this component 1724examines all values of v2 that go with a value of v1 and selects themost frequent v2 to associate with that v1 value. The number ofquadruples sharing the most frequent v2 are counted as “good” and therest of the quadruples are counted as “exceptions.” If there is only onevalue of v2 for a given v1, then the accumulated quadruples having thatvalue are good and there are no exceptions. If there is a tie for themost frequent value of v2, then the first value is selected. In theexample of table 1600, when the Zip field corresponds to f1 and theState field corresponds to f2, the component 1724 generates:(Zip/State/90019/CA, 4 good), (Zip/State/90212/CA, 2 good),(Zip/State/33102/FL, 3 good), (Zip/State/00000/FL, 1 good, 1 exception),(Zip/State/77010/TX, 1 good). When the State field corresponds to f1 andthe Zip field corresponds to f2, the component 1724 generates:(State/Zip/CA/90019, 4 good, 2 exceptions), (State/Zip/FL/33102, 3 good,1 exception), (State/Zip/TX/77010, 1 good, 1 exception).

A “global rollup f1/f2” component 1726 adds the good counts and theexceptions for each unique pair of fields f1, f2. In the example oftable 1600, when the Zip field corresponds to f1 and the State fieldcorresponds to f2, the component 1726 generates: (Zip/State, 11 good, 1exception). When the State field corresponds to f1 and the Zip fieldcorresponds to f2, the component 1726 generates: (State/Zip, 8 good, 4exceptions).

A find dependencies component 1728 uses the accumulated co-occurrencestatistics (i.e., numbers of good and exceptional records) from the“global rollup f1/f2” component 1726 to determine whether a pair offields has the relationship “f1 determines f2.” If the percentage ofexceptions (give by: number of exceptions/(number of good+number ofexceptions)) is less than the selected threshold for determining howmany exceptions to allow, then the pair of fields has the relationship“f1 determines f2.” In the example of table 1600, for a threshold of10%, when the Zip field corresponds to f1 and the State fieldcorresponds to f2, the percentage of exceptions is 8.3% and the value ofthe Zip field determines the value of the State field. When the Statefield corresponds to f1 and the Zip field corresponds to f2, thepercentage of exceptions is 33%, so the relationship between the Zip andState fields is not a one-to-one mapping. Alternatively, a value basedon a mathematical property of the accumulated values can be used todetermine whether field f1 determines field f2 (e.g., the conditionalentropy of the value of field f2 given the value of field f1, or astandard deviation of a numerical value).

7.2 Field Pair Selection Optimizations

A variety of optimizations can be applied to increase the speed offunctional dependency analysis, for example, by filtering pairs offields at the select pairs component 1706, or by filtering records atthe filter component 1712. Some optimizations are based on therecognition that some functional dependency relationships that arediscovered by the graph 1700 described above may not as meaningful to auser as others. For a given pair of fields, some of these cases can bedetected and filtered out by the select pairs component 1706 based onstatistics provided by the profiling module 100, saving computingresources. For example, if all of the values of a first field f1 areunique (each value occurring in only a single record), then the value ofthat field f1 determines the value of the second field f2 regardless ofthe values occurring in the field f2.

The graph 1700 can use census data obtained during profiling to computea probability that a first field f1 determines a second field f2 basedon a random (e.g., a uniform probability distribution) pairing of valuesin the fields. If there is a high probability (e.g., >10%) that a randompairing would result in a functional dependency, then the field pair isfiltered out by the select pairs component 1706. In the example of table1600, when the LastName field corresponds to f1 and the Citizenshipfield corresponds to f2, every random pairing of LastName withCitizenship results in all quadruples being counted as good except whenone of the name_g values (in row 7 or row 12) is randomly paired withthe value Canada. Even when this random pairing occurs (with aprobability of 16.7% (2 out of 12 pairings)), the percentage ofexceptions is only 8.3%, which is under the threshold. So in thisexample, the select pairs component 1706 filters the pair (LastName,Citizenship).

Another optimization is based on histograms of values calculated by theprofiling module 100 from census data. The select pairs component 1706filters pairs when it is not possible for field f1 to determine fieldf2. In the example of table 1600, the most frequent value of Stateoccurs 6 times and the most frequent value of a Zip occurs only 4 times.So it is not possible for the value of State to determine the value ofZip since there would be at least 2 out of 6 exceptions for at leasthalf of the values, resulting in at least a 16.7% exception percentage.So in this example, the select pairs component 1706 filters the pair(State, Zip).

For a large number of records, the graph 1700 can increase the speed oftesting for functional dependency by processing a small sample of therecords first to eliminate field pairs that are highly likely notfunctionally related before processing all of the records. The graph1700 can use the filter component 1712 to select a portion of therecords. Alternatively, the graph 1700 can use the canonicalizecomponent 1716 to select a portion of the field/value pairs.

The records or field/value pairs can be sampled based on a variety ofcriteria. The graph 1700 can sample based on statistics provided by theprofiling module 100. For example, the graph 1700 can test forfunctional dependency based on the most frequent value of first field f1(the “determiner”). If the resulting number of exceptions are higherthan the threshold, then there is no need to process the rest of valuesof the determiner. The graph 1700 can also test for functionaldependency based on a random sample of determiner values. If asufficient number of quadruples count as good among the sampled values,then the probability of finding a substantial number exceptions amongthe other values is assumed to be negligible. Other sampling criteriaare possible.

Another optional optimization is to test for pre-determined functionalrelationships between fields based on a library of known functions. Thistest can be performed on the records or on the values of the quadruples.

7.3 Functional Dependency Analysis Across Multiple Sources

In one approach for testing for functional dependency across multiplesources (e.g., database tables), profiling module 100 generates a“virtual table” that includes fields from the multiple sources. Thevirtual table can be generated, for example, by performing a joinoperation on the sources using a key field that is common to thesources.

In an example of functional dependency analysis using a virtual table, afirst data source is a database of motor vehicle registrationinformation (a motor vehicle registry (MVR) database) and a second datasource is a database of issued traffic citations (a traffic citation(TC) database). The MVR database includes fields such as make, model,color, and includes a license field that is designated as a “primarykey” field. Each record in the MVR database has a unique value of thelicense field. The TC database includes fields such as name, date,location, violation, vehicle make, vehicle model, vehicle color andincludes a vehicle license field that is designated as a “foreign key”field. Each value of the vehicle license field has a correspondingrecord in the MVR database with that value in the license field. Theremay be multiple records in the TC database having the same value of thevehicle license field.

The profiling module 100 joins records from the MVR database and TCdatabase to form a virtual table (e.g., as described above withreference to the join component 1100 shown in FIG. 11A). Each record ofthe virtual table has each of the fields from the two databasesincluding a single license field that has the matched value from the MVRlicense field and the TC vehicle license field. A record may, however,have a value of the color field from the MVR database that is differentfrom the value of the vehicle color field from the TC database. Forexample, the MVR database may use a “BLU” code to indicate the colorblue and the TC database uses a “BU” code to indicate the color blue. Inthis case, if a vehicle has the same color in both databases, the colorfield will have a “one-to-one” functional relationship with the vehiclecolor field. Alternatively, a record may have different values for thecolor field and the vehicle color field if a vehicle has been painted adifferent color in the time between being registered and receiving acitation.

Since the joined virtual table includes fields from each of multipledata sets, the profiling module 100 can discover any of a variety ofrelationships that my exist between the fields in those data sets. Thesame or similar dependency analysis as described above can be run onfields in joined virtual table.

The approaches described above can be implemented using software forexecution on a computer. For instance, the software forms procedures inone or more computer programs that execute on one or more programmed orprogrammable computer systems (which may be of various architectures,such as distributed, client/server, or grid) each including at least oneprocessor, at least one data storage system (for example, volatile andnon-volatile memory and/or storage elements), at least one input deviceor port, and at least one output device or port. The software may formone or more modules of a larger program, for example, a program thatprovides other services related to the design and configuration ofgraphs.

The software may be provided on a medium or device readable by a generalor special purpose programmable computer or delivered (encoded in apropagated signal) over a network to the computer where it is executed.All of the functions may be performed on a special purpose computer, orusing special-purpose hardware, such as coprocessors. The software maybe implemented in a distributed manner in which different parts of thecomputation specified by the software are performed by differentcomputers. Each such computer program is preferably stored on ordownloaded to a storage media or device (e.g., solid state memory ormedia, or magnetic or optical media) readable by a general or specialpurpose programmable computer, for configuring and operating thecomputer when the storage media or device is read by the computer systemto perform the procedures described herein. The inventive system mayalso be considered to be implemented as a computer-readable storagemedium, configured with a computer program, where the storage medium soconfigured causes a computer system to operate in a specific andpredefined manner to perform the functions described herein.

It is to be understood that the foregoing description is intended toillustrate and not to limit the scope of the invention, which is definedby the scope of the appended claims. Other embodiments are within thescope of the following claims.

What is claimed is:
 1. A method for processing data including: profilingdata from a data source, including reading the data from the datasource, computing summary data characterizing the data while reading thedata, and storing profile information that is based on the summary data;and processing the data from the data source, including accessing thestored profile information and processing the data according to theaccessed profile information.
 2. The method of claim 1 whereinprocessing the data from the data source further includes reading thedata from the data source.
 3. The method of claim 1 wherein profilingthe data is performed without maintaining a copy of the data outside thedata source.
 4. The method of claim 3 wherein the data includes variablerecord structure records with at least one of a conditional field and avariable number of fields.
 5. The method of claim 4 wherein computingsummary data characterizing the data while reading the data includesinterpreting the variable record structure records while computingsummary data characterizing the data.
 6. The method of claim 1 whereinthe data source includes a data storage system.
 7. The method of claim 6wherein the data storage system includes a database system.
 8. Themethod of claim 1 wherein computing the summary data includes counting anumber of occurrences for each of a set of distinct values for a field.9. The method of claim 8 wherein storing profile information includesstoring statistics for the field based on the counted number ofoccurrences for said field.
 10. The method of claim 1 further includingmaintaining a metadata store that contains metadata related to the datasource
 11. The method of claim 10 wherein storing the profileinformation includes updating the metadata related to the data source.12. The method of claim 10 wherein profiling the data and processing thedata each make use of metadata for the data source
 13. The method ofclaim 1 wherein profiling data from the data source further includesdetermining a format specification based on the profile information. 14.The method of claim 1 wherein profiling data from the data sourcefurther includes determining a validation specification based on theprofile information.
 15. The method of claim 14 wherein processing thedata includes identifying invalid records in the data based on thevalidation specification.
 16. The method of claim 1 wherein profilingdata from the data source further includes specifying datatransformation instructions based on the profile information.
 17. Themethod of claim 16 wherein processing the data includes applying thetransformation instructions to the data.
 18. The method of claim 1wherein processing the data includes importing the data into a datastorage subsystem.
 19. The method of claim 18 wherein processing thedata includes validating the data prior to importing the data into adata storage subsystem.
 20. The method of claim 19 wherein validatingthe data includes comparing characteristics of the data to referencecharacteristics for said data.
 21. The method of claim 20 wherein thereference characteristics include statistical properties of the data.22. The method of claim 1 wherein profiling the data includes profilingsaid data in parallel, including partitioning the data into parts andprocessing the parts using separate ones of a first set of parallelcomponents.
 23. The method of claim 22 wherein profiling the data inparallel further includes computing the summary data for differentfields of the data using separate ones of a second set of parallelcomponents.
 24. The method of claim 23 wherein profiling the data inparallel further includes repartitioning outputs of the first set ofparallel components to form inputs for the second set of parallelcomponents.
 25. The method of claim 22 wherein profiling the data inparallel includes reading the data from a parallel data source, eachpart of the parallel data source being processed by a different one ofthe first set of parallel components.
 26. A method for processing dataincluding: profiling data from a data source, including reading the datafrom the data source, computing summary data characterizing the datawhile reading the data, and storing profile information that is based onthe summary data; wherein profiling the data includes profiling saiddata in parallel, including partitioning the data into parts andprocessing the parts using separate ones of a first set of parallelcomponents.
 27. Software stored on a computer-readable medium includinginstructions for causing a computer system to: profile data from a datasource by reading the data from the data source, compute summary datacharacterizing the data while reading the data, and store profileinformation that is based on the summary data; and process the data fromthe data source by accessing the stored profile information and processthe data according to the accessed profile information.
 28. A dataprocessing system including: a profiling module configured to read datafrom a data source, to compute summary data characterizing the datawhile reading the data, and to store profile information that is basedon the summary data; and a processing module configured to access thestored profile information and to process the data from the data sourceaccording to the accessed profile information.
 29. A data processingsystem including: means for profiling data from a data source, includingmeans for reading the data from the data source, means for computingsummary data characterizing the data while reading the data, and meansfor storing profile information that is based on the summary data; andmeans for processing the data from the data source, including means foraccessing the stored profile information and means for processing thedata according to the accessed profile information.